Search Results: "tao"

In response to Stefano's reply to my post about Coq:

toy-ness

Usually such pieces of software are more seen as academic toys, seeing it promoted as a geeky software is a joy to me.

I really hate to detract from your happiness -- but I definitely had the word "math" implicitly stuck before "geek toy". :) Most coders that I've met are, at best, indifferent to mathematics, outright hostile at worst, so I doubt that coq will get far outside of small niches where the benefits are irresistable (security software, maybe? -- and of course pure math). I read up on this stuff despite it being utterly useless for anything I'm likely to be paid to do (unless I return to academia) because I'm a hopeless weenie loser who likes math. :P

programming-language-ness

Coq is not really a programming language (even if the CoqArt book says so, to attract the developer community), it is mainly a proof assistant; i.e. a software in which you give definitions, state theorems and prove them.

Well, this all depends on how you define programming language, which is one of those never-ending definitional questions. But using my general conception of what a programming language is, I actually have noticed two programming languages inside Coq.

The more interesting one (IMO) is the proof language they call "Gallina" and the "Vernacular", in which you construct proofs by reducing your goal to a tautology. The goal here seems to be to compute a well-typed term in Coq's core calculus, and you generally construct programs interactively: Coq shows you the current program state (expressed as one or more goals and a set of local hypotheses) and you manipulate it by (e.g.) applying lemmas to yield new known facts.

I think this language is fairly weak viewed as a programming language. It's completely unreadable and the proofs generated don't correspond to the reasoning process one normally follows when working out a proof. I am less annoyed by it now that I've learned how to do forward reasoning :), but it seems like backwards reasoning is really pushed, and that just seems .. well .. backwards to me. There's also a strong tendency to use implicitly generated names for things and to just "know" what the state of the system after issuing a command will be; as far as I can tell, the only way to understand a Coq proof is to step through it in coqide.

While it's nice to be able to "trust the kernel", it would also be nice to be able to "read a proof" directly. Among other things, their inscrutability makes me think that Coq proofs would be annoying to maintain over time. This is not necessary for stuff that's part of Principia Mathematica, but seems likely if you're developing a new theory -- in particular, I would shudder (theatrically) at the mere thought of including embedded Coq proofs in my programs.

Some additional brief comments on this were written by Nick Benton and put on the Web under the title of Machine Obstructed Proof.
The other sense is that Coq directly embeds a strongly normalizing variant of System F (I think? -- at least the simply typed LC with some type parametricity) with primitive recursion over inductive structures. This isn't Turing-complete (of course!), but I would certainly call it a real programming language.

As you note, though, this is less interesting unless you want to prove facts about your programs.

OCaml-ness

Regarding the synergy of Coq with OCaml: yes, you can prove in Coq the correctness of OCaml program, but actually not more than you can do with programs written in other programming languages

I was specifically thinking about Concoqtion; I have no idea how other projects compare, and I apologize if I incorrectly summarized it!

The wait for Debian sarge was long and painful for me, because I was trying hard to synchronise the publication of my Debian book with it, and much to my own surprise, the book was done before sarge was ready, and I had to wait. In the end, the tome left the presses only a little more than 24 hours after our release managers announced Debian 3.1 in July 2005, bundled with the second release of the official DVD, 3.1r0a. Since then, the volume has been reviewed numerous times and praised by many readers. I was especially honoured to find the title in the top ten list of most favourably reviewed books by one of my most respected reviewers, Richard Bejtlich. We are now approaching the release of Debian etch, version number 4.0, and a lot of stuff has been added or changed in Debian. I have received more than 150 emails since the etch freeze announcement, asking about an updated edition for etch, and while I am most gratious for all the feedback (and can't deny a certain amount of pride), I have to disappoint my readers, at least for now. I have not had the time to update my text, and thus cannot synchronise a new edition with the release of etch. There are a number of reasons: first, shortly after the publication of the original edition, I suffered from several physical problems, which in the end all pointed to severe muscle deformations in my back from years of wrong posture sitting at the desk. Now, one and a half years after the first symptoms appeared, I've been through numerous therapies and even though the net result is positive, I am not over the problems yet. Thus, I still try to minimise the time spent on a computer, and getting a second edition of the book out would achieve quite the opposite. Second, I am busy with my Ph.D. research, so I cannot work on the book much. It has been suggested to me to allocate minimal resources to an update, getting the text ready for etch and postponing new content to another edition. However, I would feel uncomfortable doing that. On the one hand, I'd much rather see my work be relicenced under a Creative Commons licence. So long as that is not possible, I'd rather not make people spend money without getting much in return. My book's to-do list is growing and there are many new topics which I would like to cover in the next edition (for instance: fonts, xen, more packaging topics, including modules, kernel patches, pbuilder, and packaging with version control systems). Thus, with the release of a new edition, I want to provide not only an updated version, but also one with enough content to give a fair return for people's money. I have always thought that updated-but-no-new-content editions are ripping the customers off, so I don't want to go into that direction. I am thus currently looking at the relase of the second edition together with Debian lenny, the Debian release following etch. I am looking forward to much more feedback between now and then. NP: Solar Project / Force Majeure

Devil's Pie (someones favourite window manipulation tool) 0.18 is out. Features galore in this release!

Add window_property matcher (Nigel Tao)
Add set_viewport action (James Willcox)
Add opacity action (Pavel Palat)
Add sticky action (Steve Leung)
Add unmaximise action (Alex Menk)
Add unminimise action (Richard Neill)
Fix negative offsets in geometry action (Vincent Ho, Midred)

Downloads are in the usual place.

Devil's Pie (someones favourite window manipulation tool) 0.18 is out. Features galore in this release!

Add window_property matcher (Nigel Tao)
Add set_viewport action (James Willcox)
Add opacity action (Pavel Palat)
Add sticky action (Steve Leung)
Add unmaximise action (Alex Menk)
Add unminimise action (Richard Neill)
Fix negative offsets in geometry action (Vincent Ho, Midred)

Downloads are in the usual place.

Yesterday I discovered some inadequacies in the stock Debian Etch initscripts when it came to filesystems on ATA over Ethernet block devices. Overnight I got a few emails, but it was a one Joshua J. Kugler who brought my attention to the _netdev mount option. The mount(8) manpage really is a treasure-trove of information that should be read often. So, in a nutshell, here's what I'm doing:

added _netdev to the existing options for the filesystem that is on the ATA over Ethernet device in /etc/fstab
/etc/init.d/mountall.sh modified to call mount with an extra -O no_netdev argument. Also filed #383073 to get this fixed for real.
modified /etc/init.d/mountnfs.sh (I know this is a bit off-purpose, but the comments mention smbfs being mounted, even though there's no other traces in the file) to also mount devices with the _netdev option (essentially just mount -a -O _netdev). Also filed #383123 to get this fixed for real.
modified /etc/init.d/umountnfs to unconditionally call umount -a -O _netdev (so the filesystem is unmounted before the network gets hauled out from underneath it). Also filed #383124 to get this fixed for real.

Finally, I found I had to either load the aoe kernel module as a post-up operation for the Ethernet interface in /etc/network/interfaces or load it in /etc/modules and call /usr/sbin/aoe-discover as a post-up operation in /etc/network/interfaces, because just loading it from /etc/modules resulted in the driver being loaded a fair while before the network came up, and once the network had come up, it took the driver longer than the time for /etc/init.d/mountnfs.sh to be run to realise there were ATA over Ethernet devices on the LAN and arrange for the relevant entries to appear in /dev/etherd. I've currently opted for running aoe-discover from /etc/network/interfaces. So I'm now very happy. I can reboot my MythTV server and everything comes back without any intervention whatsoever. Sweet. It'd be nice if these fixes can make it into Etch, as all of the other components will be there for ATA over Ethernet support. The kernel is new enough to have the driver as standard, and vblade is in Etch. Just the support to mount it all properly isn't there. Oh, and nothing I've done (with the exception of the post-up stuff in /etc/network/interfaces) is ATAoE-specific. It'll work equally well for NBD for example, and presumably other SAN-like stuff. I certainly find this approach far less gross than what Coraid suggests, and it'd also be cool if Debian were the first distro to do it the right way. I wonder if Red Hat/Fedora are already? I suppose I could fire up Xen or VMware and find out if I get curious enough.

When I did my Red Hat Certified Engineer training, the second time around (when I updated from Red Hat 7.1 to Enterprise Linux 3), the trainer mentioned this Ext3 vs Reiserfs benchmark that Gurulabs performed. Probably because it had such a memorable name, I've remembered it and referred people to it, and referred to it myself, a few times over the years since. So it seemed only fair to try out their benchmarking methods (i.e. use NetApp's postmark with a few different settings) on the uber-disk as well, while I had it idle. So I did. Firstly, I ran it locally on minotaur, the piddling little 866Mhz Pentium III, with 320Mb of RAM (but with 1.5Tb of disk attached directly via USB), and then I ran the exact same tests from teevee, the box destined to become my MythTV server (3.0Ghz Pentium 4, 1Gb of RAM), with the disks mounted with ATA over Ethernet. This was with a JFS filesystem on a single logical volume striped across four physical volumes. I ran the tests three times, just like the Gurulabs benchmark, first time around, it was with:

50,000 transactions (set transactions 50000)
2,000 simultaneous files (set number 2000)
files in the range of 1,000 to 9,000 bytes (set size 1000 9000)

The idea being that this will generate around 150Mb of data, which should all fit in the RAM (of either system) The second time around was with:

50,000 transactions
2,000 simultaneous files
files in the range of 1,000 to 90,000 bytes

The idea being that this, generating 1400Mb of data, will exceed the RAM on both systems (but not uniformally, obviously). The final run was a total thrash with:

200,000 transactions
4,000 simultaneous files
files in the range of 1,000 to 300,000 bytes

This one causes about 19Gb of data to be written, and absolutely hammers the living daylights out of the disks (or the network, and the disks, in the case of ATAoE). So, now for the results:

Test case 1, with locally attached disks

Time:
        22 seconds total
        21 seconds of transactions (2380 per second)
Files:
        27170 created (1235 per second)
                Creation alone: 2000 files (2000 per second)
                Mixed with transactions: 25170 files (1198 per second)
        24986 read (1189 per second)
        24697 appended (1176 per second)
        27170 deleted (1235 per second)
                Deletion alone: 2340 files (2340 per second)
                Mixed with transactions: 24830 files (1182 per second)
Data:
        149.53 megabytes read (6.80 megabytes per second)
        161.85 megabytes written (7.36 megabytes per second)

Test case 1, with ATAoE attached disks

Time:
        27 seconds total
        25 seconds of transactions (2000 per second)
Files:
        27170 created (1006 per second)
                Creation alone: 2000 files (2000 per second)
                Mixed with transactions: 25170 files (1006 per second)
        24986 read (999 per second)
        24697 appended (987 per second)
        27170 deleted (1006 per second)
                Deletion alone: 2340 files (2340 per second)
                Mixed with transactions: 24830 files (993 per second)
Data:
        149.53 megabytes read (5.54 megabytes per second)
        161.85 megabytes written (5.99 megabytes per second)

Findings

A degradation in performance, sure, but not a huge one.

Test case 2, with locally attached disks

Time:
        218 seconds total
        209 seconds of transactions (239 per second)
Files:
        27144 created (124 per second)
                Creation alone: 2000 files (400 per second)
                Mixed with transactions: 25144 files (120 per second)
        24830 read (118 per second)
        25094 appended (120 per second)
        27144 deleted (124 per second)
                Deletion alone: 2288 files (572 per second)
                Mixed with transactions: 24856 files (118 per second)
Data:
        1405.24 megabytes read (6.45 megabytes per second)
        1535.91 megabytes written (7.05 megabytes per second)

Test case 2, with ATAoE attached disks

Time:
        165 seconds total
        158 seconds of transactions (316 per second)
Files:
        27144 created (164 per second)
                Creation alone: 2000 files (1000 per second)
                Mixed with transactions: 25144 files (159 per second)
        24830 read (157 per second)
        25094 appended (158 per second)
        27144 deleted (164 per second)
                Deletion alone: 2288 files (457 per second)
                Mixed with transactions: 24856 files (157 per second)
Data:
        1405.24 megabytes read (8.52 megabytes per second)
        1535.91 megabytes written (9.31 megabytes per second)

Findings

Whoa, who'd have thought this? Better performance over the wire? I'm blaming the fact that minotaur is a bit of a weakling compared to teevee, and teevee had a better caching advantage with more RAM. Mind you, you'd expect to see the same for the first test as well, unless size is a factor. Inconclusive results I guess.

Test case 3, with locally attached disks

Time:
        7356 seconds total
        7310 seconds of transactions (27 per second)
Files:
        104099 created (14 per second)
                Creation alone: 4000 files (117 per second)
                Mixed with transactions: 100099 files (13 per second)
        100246 read (13 per second)
        99560 appended (13 per second)
        104099 deleted (14 per second)
                Deletion alone: 4198 files (349 per second)
                Mixed with transactions: 99901 files (13 per second)
Data:
        18995.06 megabytes read (2.58 megabytes per second)
        19738.85 megabytes written (2.68 megabytes per second)

Test case 3, with ATAoE attached disks

Time:
        12320 seconds total
        12111 seconds of transactions (16 per second)
Files:
        104099 created (8 per second)
                Creation alone: 4000 files (32 per second)
                Mixed with transactions: 100099 files (8 per second)
        100246 read (8 per second)
        99560 appended (8 per second)
        104099 deleted (8 per second)
                Deletion alone: 4198 files (49 per second)
                Mixed with transactions: 99901 files (8 per second)
Data:
        18995.06 megabytes read (1.54 megabytes per second)
        19738.85 megabytes written (1.60 megabytes per second)

Findings

So presumably the network latency made its presence felt with data volumes of this magnitude.

91	D63469DF	dnusinow	1243
63	DEB0EC31	eloy
55	A965818F	vela	1243
46	58510B5A	myon	2143
39	9B7C328D	luk	31-2
39	1880283C	anibal	2134
37	0FE53DD9	opal	4213
32	2B0920C0	lool	1342
29	788A3F4C	joeyh
27	0F932C9C	doko
25	8768B1D2	sjoerd
23	F1BCDB73	aurel32	13-2
19	E02FEF11	jordens	1243
18	AB963370	schizo	1243
18	6E74A7D1	jdassen(Ks)	1243
18	68FD549F	tbm	3142
18	6783ED5E	fpeters	1--2
17	91B0D3B7	edd	-213
16	E07F1CF9	rousseau	321-
16	248AEB73	rene	1243
15	8E635A5E	rafl
14	C0143D2D	bubulle	4123
13	D87C6781	krooger(P)	4213
13	A436AD25	jfs(P)
13	3D08B612	msp
13	1E880A84	fjp	4213
13	0F7A8D01	nobse
12	F1968D1B	decklin	1234
12	E7075A54	mhatta
12	D75F8533	joss	1342
12	BF24424C	srivasta	1342
12	B8C1FA69	sto
12	7F961564	kobold
12	2A30D729	pere	4213
12	16D970C6	eric	12--
11	5E0577F2	mpitt
11	307D56ED	noel	3241
11	2BE16D01	moray	1342
10	BC7D020A	formorer	-1--
10	A7D91602	apollock	4213
10	A51A4FDD	gcs
10	917A225E	jordi
10	4B729625	pvaneynd	3123
10	497A176D	loic
9	62F1A57F	pa3aba
9	54FD2A58	glandium	1342
9	4A5D72FE	rafael
9	13FEFC40	fenio	-1--
9	0AFC7476	rra	1243
8	90267086	duck	31-2
8	86A118E6	ch	321-
8	801EA932	joey	1243
8	7F4E0E11	waldi	-123
8	514B3E7C	florian	21--
8	41954920	fs	12--
8	2A385C57	mckinstry	21-3
8	25BFB848	rleigh	1243
7	BC70A6FF	pape	1---
7	B70E403B	ari	1243
7	8E2D213A	jochen(Ks)
7	85FEC17F	kilian
7	84FB46D6	lwall	1342
7	800969EF	smimram	-1--
7	79CC6586	haas
7	5BFA90EC	kohda
7	52B7487E	sesse	2341
7	29499F61	sho	1342
7	1E161AFB	barbier	12--
6	FC05DA69	wildfire(P)
6	EEB6B4C2	avdyk	-12-
6	EDF008C5	blade	1243
6	E25F2102	mejo	1342
6	D1C41882	adeodato(Ks)	3142
6	D0B433DF	ross	12-3
6	B0EBC777	piman	1233
6	9D309C3B	robert	4213
6	882A6C4B	kov
6	6BBA3C84	zugschlus	4213
6	5662C734	mvo
6	554FB4C6	petere	-1-2
6	37155778	stratus
6	2D9ACC8E	lars	1243
6	2809E61A	josem
6	2252FA1A	frank	2143
6	1CF2D62A	micah
6	10FA4CD1	cjwatson	2143
5	EE6DC66A	jaldhar	2143
5	EA59038E	sgran	4123
5	E1EE3FB1	md	4312
5	E0B8B2DE	jaybonci
5	C9A5B54E	sesse(Ps	,Gs) 2341
5	C4CF8EC3	twerner
5	C2FEE5CD	acid	213-
5	C09FD35A	tille
5	C03C56DF	rfrancoise	---1
5	B7CDA2DC	xam	213-
5	A20EBC50	cavok	4214
5	808D0FD0	don	1342
5	797EBFAB	enrico	1243
5	5230514A	sjackman
5	49A5F855	otavio	-123
5	3DC29B41	pdm
5	29982E5A	vorlon	1243
5	2763483B	mkoch	213-
5	21DB31C5	smr	2143
5	1BF8DE0F	stigge	312-
5	12CADFA5	csmall	3214
5	0A0AC927	lamont
4	F2CF01A8	bdale
4	F095E5E4	mnencia
4	E9F2C747	frankie
4	E9ABFCD2	devin	2143
4	E81E55C1	dancer	2143
4	E38E7ACF	hmh(Gs)	1243
4	E298966D	jrv(P)
4	DF5CE2B4	huggie	12-3
4	DD982A75	speedblue
4	C671257D	damog	-1-2
4	C4A3823E	kmr	4213
4	C0B10A5B	dexter
4	C02440B8	js	1342
4	BE9F70EA	tb	1342
4	B7D2F063	varenet	-213
4	A3F9E30E	schultmc	1243
4	A3D7B9BC	lawrencc	2143
4	A1EE761C	madcoder	21--
4	9DE1EEB1	he	3142
4	9D928C9B	guillem	1---
4	9B726B71	racke
4	90788E11	jsogo	2143
4	864826C3	gotom	4321
4	7244970B	kroeckx	2143
4	5B48FFAE	marga	2143
4	54E672DE	isaac	1243
4	4B3A135C	erich	1243
4	4597A593	agmartin	4213
4	3FCC2A90	amaya	1243
4	3F3E6426	agx	-1-2
4	3EF23CD6	sanvila	1342
4	32C9C8BD	werner(K)
4	204DDF1B	aquette
4	00D8CD16	tolimar	12--
3	FEC23FB2	bap	34-1
3	F972BE03	tmancill	4213
3	F801A743	nduboc	1---
3	EBEDB32B	chrsmrtn	4123
3	EA291785	taggart	2314
3	E4D47EC1	tv(P)
3	E19F188E	troyh	1244
3	DF6807BE	srk	4213
3	D2A913A1	psg(P)
3	D097A261	chrisb
3	C6CEA0C9	adconrad	1243
3	C20DF273	ondrej
3	B5444815	ballombe	1342
3	B1DF9A57	cate	2143
3	AFA44BDD	weasel(Ps	,Gs) 1342
3	AA6541EE	brlink	1442
3	A824B93F	asac	3144
3	A71C1E00	turbo
3	A2D7D292	seb128
3	9ED101BF	mbanck	3132
3	969457F0	joostvb	2143
3	89BF7E2B	kobras	1--2
3	86946D69	mooch	12-3
3	74886B63	nathans
3	6F222F1F	edelhard
3	6D67F790	foka
3	60B6B958	geiger
3	607559E6	mako
3	5C33C1B8	dirson
3	5921B5D8	ajmitch
3	4C1A5BE5	sjq
3	431B38BA	pxt	312-
3	3E7B4B73	lmamane	2143
3	27572C47	ucko	1342
3	20021490	schepler	1342
3	1DEB8EAE	goedson
3	1BF2305A	krala(Gs)	3142
3	19A42D19	dannf	21-4
3	174FEE35	wookey	3124
3	124B26F3	mfurr	21-3
3	0A327652	tschmidt	312-
3	090DD8D5	ingo	3123
3	0813569F	jeroen	1141
3	0644FAB7	bas	1332
3	0123F2F2	gareuselesinge	1243
3	00530C24	bam	1234
2	FD6645AB	rmurray	-1-2
2	F95C2F6D	chrism(P)
2	F9138496	graham(Gs)	3142
2	F5D65169	jblache	1332
2	F28CD102	absurd
2	F2597E04	samu
2	F0B27113	patrick
2	EFA6B9D5	hamish(P)	3142
2	EE0A35C7	risko	4213
2	E91CD250	daigo
2	D688E0A7	qjb	-21-
2	D4BE1450	prudhomm
2	D2A6B810	joussen
2	CFD42F26	dilinger
2	CEE44978	dburrows	1243
2	CD4C0D9D	skx	4213
2	BFB880A3	zeevon
2	BD8B050D	roland	3214
2	B74952A9	alee
2	B4D6DE13	paul
2	B345BDD3	neilm	1243
2	B28C5995	bod	4213
2	B0FA4F49	schoepf
2	B0DDAF42	awoodland
2	A8061F32	osamu	4213
2	A21AD4F9	tviehmann	1342
2	99E81DA0	kaplan
2	964199E2	fabbe	3142
2	8DBFEC2F	pelle
2	8B8D7663	ametzler	1342
2	8B143975	martignlo
2	88C7C1F7	93sam	2134
2	83E5110F	ovek
2	817A996A	tfheen
2	807CAC25	abi	4123
2	798DD95C	piefel
2	78D621B4	uwe	-1--
2	6FF0ABF2	rcw	2143
2	6E8169D2	hertzog	3124
2	6C0084FC	chrisvdb
2	6B79D401	filippo	-1--
2	67756F5D	frn	2341
2	5E2EB5B4	nveber	123-
2	5C6153AD	broonie	1243
2	5B713DF0	djpig	1243
2	50ECFB98	ccontavalli(Gs)
2	50064181	paulvt
2	4F71955A	dajobe	21-3
2	4E2ECA5A	jmm	4213
2	496A1827	srittau
2	3E8DCCC0	maxx	1342
2	3D97C149	mstone(P)	2143
2	2DB65596	dz	321-
2	29F19BD1	meskes
2	1F41B907	marillat	1---
2	1EB2DE66	boll
2	1557BC10	kraai	1342
2	144843F5	lolando	1243
2	10656584	voc
2	0D7CA701	steinm
2	05410E97	horms
1	FC992520	tpo	-14-
1	FB0DFE9B	gildor
1	FAEEB4A9	neil	1342
1	F7E8BC63	cedric	21--
1	F2C423BC	zack	1332
1	F0199162	kreckel	4214
1	ECA94FA8	ishikawa	2143
1	EAAC62DF	cyb	---1
1	EA2D2C41	malattia	-312
1	E77AC835	bcwhite(P)
1	E66C9BB0	tach
1	E145F334	mquinson	2143
1	E0BA04C1	treinen	321-
1	DFE80FB2	tali
1	DE054F69	azekulic(P)
1	DC814B09	jfs
1	CB467E27	kalfa
1	C9132DDB	yoush	-21-
1	C87FFC2F	stevenk	-1--
1	C2CE8099	knok	321-
1	BED37FD2	henning(Ks)	1342
1	BA0A7EB5	treacy(P)
1	B7D86E0F	cmb	4213
1	B62849B3	smarenka	2143
1	B3C281F4	alain	2143
1	B25A5CF1	omote
1	ABA0E8B2	sasa
1	AB474598	baruch	2143
1	AB2A91F5	troup	1--2
1	A827CEDE	afayolle(Gs)
1	A6C805B9	zorglub	2134
1	A674A359	maehara
1	A57D8BF7	drew	2143
1	A269D927	sharky
1	A1696D2B	lfousse	1232
1	9BF42B07	zinoviev	--12
1	9057B5D3	vanicat	2143
1	8E950E00	mechanix
1	8BB527AF	gwolf	1132
1	8A1D9A1F	jgoerzen
1	8807529B	ultrotter	2134
1	872EB4E5	rcardenes
1	85EE3E0E	angdraug	12-3
1	835EB2FF	bossekr
1	80C83E8E	igloo	1243
1	7B8357E5	andreas	212-
1	7B80220D	sjr(Gs)	1342
1	7796A60B	sfllaw	1342
1	75CB1AD2	toni	1---
1	746C51F4	klindsay
1	72D03CB1	kmuto	4231
1	71473F66	ttroxell	13-4
1	6E76D81D	seanius	1243
1	6C63746D	hector
1	6C5F196B	malex	4213
1	6A9F3C38	rkrishnan
1	68021CE4	ron	---1
1	66F24521	pyro	-123
1	631B4819	anfra
1	62EEAD8B	falk	1342
1	61326D40	jamessan	13-4
1	609CD2C0	berin	--1-
1	5D8CDA7B	guus	1243
1	5D8C12EA	rganesan
1	5D64F870	zobel
1	59EF5DBC	bs
1	57F045DC	camm
1	564EE4B6	hazelsct
1	5623FC45	moronito	4213
1	551BE447	torsten
1	54AD21B5	warmenhoven
1	53BBA490	sjg
1	532005DA	seamus
1	50973B91	pjb	2143
1	4F83C751	kmccarty	12-3
1	4DB97694	khkim
1	4CD6E3D2	wjl	4213
1	4A8854E6	weinholt	1243
1	4950EAA6	ajkessel
1	4298C761	robertc(Ks)
1	42955682	kamop
1	3FD29468	bengen	-213
1	3FD25C84	roktas	3142
1	3B047084	madhack
1	39CCF0C7	tagoh	3142
1	39A8CCE2	eugen	31-2
1	38015E7E	thb	1234
1	36B861C1	bab	2143
1	33FC40A4	mennucc1	3214
1	2C0FCD1A	wdg	4312
1	2B05B73A	rjs
1	258D8781	grisu	31-2
1	206C5AFD	chewie	-1-1
1	200D1596	joy	2143
1	1C74E0B7	alfs
1	19D03486	francois	4123
1	18EA3457	rvr
1	176015ED	evo
1	16BD77C6	alfie
1	12AA1DB8	jh
1	128287E8	daf
1	09FC015C	godisch
1	06468DEB	fog	--12
1	05792F34	rla	-21-
1	028AF63C	forcer	3142
1	004DA6B4	bg66
0	.	zufus	-1--
0	.	zoso	-123
0	.	ykomatsu	-123
0	.	xtifr	1243
0	.	xavier	-312
0	.	wouter	2143
0	.	will	-132
0	.	warp	1342
0	.	voss	1342
0	.	vlm	2314
0	.	vleeuwen	4312
0	.	vince	2134
0	.	ukai	4123
0	.	tytso	-12-
0	.	tjrc1	4213
0	.	tats	-1-2
0	.	tao	1--2
0	.	stone	2134
0	.	stevegr	1243
0	.	smig	-1-2
0	.	siggi	1-44
0	.	shaul	4213
0	.	sharpone	1243
0	.	sfrost	1342
0	.	seb	-21-
0	.	salve	4213
0	.	ruoso	1243
0	.	rover	--12
0	.	rmayr	-213
0	.	riku	4123
0	.	rdonald	12-3
0	.	radu	-1--
0	.	pzn	112-
0	.	pronovic	1243
0	.	profeta	321-
0	.	portnoy	12-3
0	.	porridge	1342
0	.	pmhahn	4123
0	.	pmachard	1--2
0	.	pkern	3124
0	.	pik	1--2
0	.	phil	4213
0	.	pfrauenf	4213
0	.	pfaffben	2143
0	.	p2	1243
0	.	ossk	1243
0	.	oohara	1234
0	.	ohura	-213
0	.	nwp	1342
0	.	noshiro	4312
0	.	noodles	2134
0	.	nomeata	2143
0	.	noahm	3124
0	.	nils	3132
0	.	nico	-213
0	.	ms	3124
0	.	mpalmer	2143
0	.	moth	3241
0	.	mlang	2134
0	.	mjr	1342
0	.	mjg59	1342
0	.	merker	2--1
0	.	mbuck	2143
0	.	mbrubeck	1243
0	.	madduck	4123
0	.	mace	-1-2
0	.	luther	1243
0	.	luigi	4213
0	.	lss	-112
0	.	lightsey	1--2
0	.	ley	-1-2
0	.	ldrolez	--1-
0	.	lange	4124
0	.	kirk	1342
0	.	killer	1243
0	.	kelbert	-214
0	.	juanma	2134
0	.	jtarrio	1342
0	.	jonas	4312
0	.	joerg	1342
0	.	jmintha	-21-
0	.	jimmy	1243
0	.	jerome	21--
0	.	jaqque	1342
0	.	jaq	4123
0	.	jamuraa	4123
0	.	iwj	1243
0	.	ivan	2341
0	.	hsteoh	3142
0	.	hilliard	4123
0	.	helen	1243
0	.	hecker	3142
0	.	hartmans	1342
0	.	guterm	312-
0	.	gniibe	4213
0	.	glaweh	4213
0	.	gemorin	4213
0	.	gaudenz	3142
0	.	fw	2134
0	.	fmw	12-3
0	.	evan	1--2
0	.	ender	4213
0	.	elonen	4123
0	.	eevans	13-4
0	.	ean	-1--
0	.	dwhedon	4213
0	.	duncf	2133
0	.	ds	1342
0	.	dparsons	1342
0	.	dlehn	1243
0	.	dfrey	-123
0	.	deek	1--2
0	.	davidw	4132
0	.	davidc	1342
0	.	dave	4113
0	.	daenzer	1243
0	.	cupis	1---
0	.	cts	-213
0	.	cph	4312
0	.	cmc	2143
0	.	clebars	2143
0	.	chaton	-21-
0	.	cgb	-12-
0	.	calvin	-1-2
0	.	branden	1342
0	.	brad	4213
0	.	bnelson	1342
0	.	blarson	1342
0	.	benj	3132
0	.	bayle	-213
0	.	baran	1342
0	.	az	2134
0	.	awm	3124
0	.	atterer	4132
0	.	andressh	1---
0	.	amu	1--2
0	.	akumria	-312
0	.	ajt	1144
0	.	ajk	1342
0	.	agi	2143
0	.	adric	2143
0	.	adejong	1243
0	.	adamm	12--
0	.	aba	1143

Artist: Mr. Garrison Lyrics
Song: Merry Fucking Christmas Lyrics
Mr. Garrison: I heard there is no Christmas
In the silly Middle East
No trees, no snow, no Santa Claus
They have different religious beliefs They believe in Muhammad
And not in our holiday
And so every December
I go to the Middle East and say… “Hey there Mr. Muslim
Merry fucking Christmas
Put down that book the Koran
And hear some holiday wishes. In case you haven’t noticed
It’s Jesus’s birthday.
So get off your heathen Muslim ass
and fucking celebrate. There is no holiday season in India I’ve heard
They don’t hang up their stockings
And that is just absurd! They’ve never read a Christmas story.
They don’t know what Rudolph is about
And that is why in December
I’ll go to India and shout… Hey there Mr. Hinduist
Merry fucking Christmas
Drink eggnog and eat some beef
And pass it to the missus. In case you haven’t noticed
It’s Jesus’s birthday
So get off your heathen Hindu ass
and fucking celebrate! Now I heard that in Japan
Everyone just lives in sin
They pray to several gods
And put needles in their skin. On December 25th
All they do is eat a cake
And that is why I go to Japan
And walk around and say… Hey there Mr. Shintoist
Merry fucking Christmas
God is going to kick your ass
You infidelic pagan scum. In case you haven’t noticed
There’s festive things to do
So lets all rejoice for Jesus
And Merry fucking Christmas to you. On Christmas day I travel round the world and say,
Taoists, Krishnas, Buddhists, and all you atheists too,
Merry Fucking Christmas, To You! (Clapping) Thank you Mr. hat

Search Results: "tao"

13 April 2007

Daniel Burrows: coq's -ness-nesses

15 January 2007

Martin F. Krafft: Status of my book

20 October 2006

Ross Burton: Devil's Pie "Simmer To A Sizzle Like The Days Of Old" 0.18

Ross Burton: Devil's Pie "Simmer To A Sizzle Like The Days Of Old" 0.18

15 August 2006

Andrew Pollock: [tech] How to mount ATA over Ethernet volumes with a minimum of grossness

13 August 2006

Andrew Pollock: [tech] More benchmarking

19 March 2006

Clint Adams: This report is flawed, but it sure is fun

24 December 2005

Adam Heath: Merry ChristmasHappy Holidays